NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/3743

Internet Message Format | 1996-08-05 | 4.0 KB

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.c
Subject: Re: End of File
Date: 30 Jan 1996 23:35:23 GMT
Organization: Los Alamos National Laboratory
Message-ID: <[e-mail]>
References: <4edr5q$[e-mail]> <[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: "Eric W. Bradway"'s message of Tue, 30 Jan 1996 12:55:07 -0500

In article <[e-mail]> "Eric W. Bradway"
<[e-mail]> writes:
   Unregistered wrote:
   >
   > How does one set the file pointer to end of file on a binary file in C.

   fseek(file, 0L, SEEK_END);

There is no portable solution: the above will work on some
implementations.

The basic problem is that the `end' of a binary file is not a well
defined concept. As arbitrary characters can be written to a binary
file with the expectation of being able to read back unchanged, it may
not be able to support `out of band' data to mark the end of the file
without additional overhead. This end of file determination is often
(though it is certainly not required to be) handled at the OS level
which may try to minimize this overhead by allowing files of only
certain sizes (e.g. multiples of a logical block etc.) The C standard
allows for this by saying that when a binary file is written and read
back, additional '\0' (i.e. null characters) may be read back which
were never written out: in other words, the implementation is allowed
to pad the file with zeros. (The implementation has to document how
many zeros are added if any.) This results in an ambiguity in the
definition of the end of file in a binary file (because the zeros may
be added only when the file is closed and not before), and the
implementation is allowed to not meaningfully support the concept of
an end of file for a binary file.

For text files, as only printable characters, '\t' and '\n' can
be written with the expectation of being read back unchanged (with
further restrictions irrelevant to our discussion: required '\n' at
the end of file and no blanks at end of line; the implementation has
to document what happens if the second of these is violated), the
implementation has a way of marking the end of file very simply (say
with a '\0' or '\032'). Historically, therefore, text files could be
of any length: and the C standard requires the end of file to be a
meaningful concept. In this case however, the usual end of line on the
system may be different from that required by the C standard (i.e. eol
may be represented by something other than '\n'), which means that
characters in a text file may not `stand for themselves'. So the
standard allows the offsets not to be counted in real characters (for
example they could easily be the number of bytes in the external
representation of the file, or in the internal): all that is required
is that ftell and fseek use the same method of counting (naturally). A
value of zero however has a fixed meaning in any method of counting,
and is allowed. So, the fseek call above would have worked for a text
file.

Note that technically the above refers to text streams and binary
streams. An implementation may or may not have separate concepts for
text and binary `files', and if it supports the concept, an fopen of a
binary file as a text stream (or vice-versa) might fail.

Everything above is to rationalize the rules of ANSI C, to make them
understandable (like mnemonics). I do not claim that they reflect any
or all of historical basis of the rules.

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]